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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 



Introduction 



Electronic commerce is emerging as the future way of doing business between companies across local, wide area and 
global networks. Trust in this way of doing business is essential for the success and continued development of 
electronic commerce. It is therefore important that companies using this electronic means of doing business have 
suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with 
their business partners. In this respect the electronic signature is an important security component that can be used to 
protect information and provide trust in electronic business. 

The European Directive on a community framework for Electronic Signatures [i.3] (also denoted as "the Directive" or 
the "European Directive" in the rest of the present document) defines an electronic signature as: "data in electronic form 
which is attached to or logically associated with other electronic data and which serves as a method of authentication". 

TS 101 733 [1] and TS 101 903 [2] define formats for electronic signatures in line with the Directive. These formats 
include modes of use whereby the signature is detached from the data to which it is appUed. 

The present document specifies the use of container structures for associating either detached CAdES signatures or 
detached XAdES signatures or time-stamp tokens, with one or more signed objects to which they apply. 

Extending protection for archived document using techniques such as of archive time-stamp following construction of 
an ASiC container is not addressed by the current version of the present document. 

Protection of data objects outside the container is not in scope and no reference to external data object is allowed. 
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Scope 



The present document specifies the use of container structures, to bind together a number of signed objects 
(e.g. documents, XML structured data, spreadsheet, multimedia content) with either detached advanced electronic 
signatures or time-stamp tokens into one single digital container based on ZIP [8] and supporting the following 
signature and time-stamp token formats: 

• CAdES (TS 101 733 [1]); 

• XAdES (TS 101 903 [2]); 

• RFC 3161 [3] time-stamp tokens. 

NOTE 1 : No restriction is placed on the format of time-stamp tokens used within CAdES/XAdES. 

Other time-stamp token formats and methods could be considered in future versions of the present document. 

A number of application environments use ZIP based container formats to package sets of data objects together with 
meta-information. ASiC technical specification is designed to operate with a range of such ZIP based application 
environments. Rather than enforcing a single packaging structure ASiC describes how these container formats can be 
used to associate advanced electronic signatures with any data objects. In particular, the present documents aim is to 
work with implementations of OCF (OEBPS Container Format), ODE (Open Office), UCE or any similarly structured 
container format to also comply with one of the modes of use ASiC. It is also the aim of the present document to 
address use of "virtual dossiers" container formats such as required in some pan-European projects. 

• Clause 4 provides a general introduction and background to ASiC. 

• Clause 5 describes simple form which can be used for basic use cases where a single data object (e.g. a 
document), or a container has to be signed. 

• Clause 6 describes extended form for use cases providing much greater flexibility in data objects protected by 
an individual signature. 

• Clause 7 defines conformance requirements for ASiC implementations. 

• Annex A specifies container metadata and referencing rules. 

• Annex B gives examples of the use of the ASiC for particular applications. 

New elements are defined in the present document to support additional features such time-stamping and CAdES 
signing of multiple content and XAdES parallel signatures that may be used in other contexts. 

The present document offers a basic support for TSTs, since it does not currently address: 

• the identification of the validation policy to be used for verifying a container that contains the TST; 

• the data that contains the certification path and related revocation information to verify the TST. 

NOTE 2: In the present version of this document reference to documents outside the container is not allowed and 
long term verification of time-stamping and extended forms is out of scope. 
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References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[I] ETSI TS 101 733: "Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic 
Signatures (CAdES)". 

[2] ETSI TS 101 903: "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic 

Signatures (XAdES)". 

[3] IETF RFC 3161: "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". 

[4] Void. 

[5] ISO 32000-1 : "Document management - Portable document format - Part 1 : PDF 1 .7". 

NOTE: Available at http://www.adobe.com/devnet/acrobat/pdfs/PDF32000 2008.pdf . 

[6] Void. 

[7] IDPF "OEBPS Container Format (OCF)". 

NOTE: Available at http://idpf org/epub/30/spec/epub30-ocfhtml . 

[8] PKWARE ".ZIP Application Note". 

NOTE: Available at http://www.pkware.com/support/zip-application-note . 

[9] OASIS "Open Document Format for Office Applications (OpenDocument) Version 1.2 

Part 3: Packages", Committee Specification 01. 

[10] W3C recommendation: "XML Signature Syntax and Processing". 

[II] IETF RFC 4288: "Media Type Specifications and Registration Procedures". 
[12] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax". 

[13] ETSI TS 101 861: "Electronic Signatures and Infrastructures (ESI); Time stamping profile". 



2.2 



Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 



[i.l] 



Adobe "Universal Container Format (UCF)". 



NOTE: Available at http://livedocs.adobe.eom/navigatoi-/9/Navigator SDK9 HTMLHelp/ 
Appx Packaging. 6.1. html . 



[i.2] 



ISO 15489-1: "Information and documentation - Records management - Part 1: General". 
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[i.3] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a 

Community framework for electronic signatures. 

[i.4] OASIS "Guidelines to Writing Conformance Clauses", 4 September 2007. 

NOTE: Available at http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html . 

[i.5] ETSI Drafting Rules (EDRs). 

NOTE: Contained in the ETSI Directives: http://portal.etsi.org/Directives/home.asp . 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 101 733 [1], TS 101 903 [2] and the 
following apply: 

Conformance Clause: statement of a specification that provides a high-level description of what is required for an 
implementation to conform by referring to other parts of the specification for details 

NOTE 1: A Conformance Clause references one or more Normative Statements, directly or indirectly, and can refer 
to another Conformance Clause. 

NOTE 2: Derived from [i.4]. 

container: file holding data objects with related manifest, metadata and associated signature(s), under a specified 
hierarchy 

data object: any digital information to which Advanced Electronic Signature(s) and/or time-stamping are applicable 

may: means that a course of action is permissible within the limits of the present document 

metadata: data describing context, content and structure of data objects and their management over time 

NOTE: Refer to ISO 15489-1: 2001, definition 3.12 with modifications [i.2]. 

The present document makes use of certain key words to signify requirements. Below follows their definitions: 

recommended: See should. 

shall: used to indicate requirements strictly to be followed in order to conform to the present document and from which 
no deviation is permitted 

NOTE Use of verbal forms shall, shall not and should, conform to ETSI Drafting Rules (EDRs), clause 14a [i.5]. 

should: means that among several possibilities one is recommended as particularly suitable, without mentioning or 
excluding others, or that a certain course of action is preferred but not necessarily required 

NOTE: Implementers may know valid reasons in particular circumstances to ignore this recommendation, but the 
full implications must be understood and carefully weighed before choosing a different course. 

ZIP: data object conformant to [8] 
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3.2 Abbreviations 



For the purposes of the present document, the abbreviations given in ISO 32000-1 [5], TS 101 733 [1] and the following 
apply: 

AdES Advanced Electronic Signature 

ASiC Associated Signature Container 

OCF OEBPS Container Format 

NOTE: Refer to [7]. 

ODF Open Document Format 

NOTE: Refer to [9]. 

OEBPS Open eBook Publication Structure 

UCF Universal Container Format 

NOTEl: Refer to [i.l]. 

NOTE 2: Refer to [2]. 



4 Introduction to Associated Signature Containers 

(informative) 

4.1 Requirements addressed by Associated Signature 
Containers 

When signing data, the resultant signature needs to be associated with the data to which it applies. This can be achieved 
either by creating a data set which combines the signature and the data that was signed (e.g. by enveloping the data with 
the signature or including a signature element in the data set) or placing the (detached) signature in a separate resource 
and have some external means for associating the signature with the data to which it applies. While there are some 
advantages to the use of detached signatures, most significantly their non-modification of the original data objects, there 
remains a risk that the signature becomes separated from the data to which it applies and so losing the association. 
Therefore, many application systems have developed their own technique for combining a detached signature with the 
signed object in some form of container so that they can be more easily distributed and guarantee that the correct 
signature and any relevant metadata is used when verifying. The same requirements applies to associate a time-stamp 
token to its related data. 

The present document defines a standardized use of container forms to establish a common way for associating data 
objects with advanced signatures or time-stamp tokens. Using a common container form and associated information 
will enable a greater amount of interchange and interoperability among various signing and verification services. 

Whilst ZIP [8] provides a basic container structure that can associate data objects and the signature(s) that apply to 
them, there is a recognised need for additional structure and metadata about the association, for example to link a 
particular signature with the data object to which it is applied. Other formats have already been specified for the use of 
ZIP based structures to bind together a number of data objects with related metadata. This includes OCF [7] (OEBPS 
Container Format) which was originally designed for use by eBooks but has been adopted as the basis for other 
containers including that used by ODF [9] (Open Document Format - Open Office) and UCF [i.l] (Universal Container 
Format by Adobe Systems). The present document builds on this work specifically addressing the requirements of 
associating an advanced electronic signature with any type of data, independent of the needs of any particular document 
or data type. The present document can be used for any type of virtual dossier types that collects together electronic 
documents including those supported by OCF, ODF and UCF. 
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4.2 Main features of Associated Signature Containers 

4.2.1 Basic container structure 

The ASiC is a data container holding a set of data objects and associated signatures using the ZIP [8] format. The ZIP 
format was chosen as it is used by many popular container formats and it is natively supported by most operating 
systems. 

Any ASiC container has an internal structure including: 

• a root folder, for all the container content possibly including folders reflecting the content structure; 

• a META-INF folder, in the root folder, for metadata about the content, including associated signatures. 

The detached signatures are applied in a way such that the integrity of the data is not broken when the signed objects are 
extracted from the ZIP container. Hence, the signatures used in ASiC can be verified against the protected data objects 
when outside the container structure (for example when placed in local storage). 

4.2.2 Container types 

The present document defines two types of containers. 

The first type (ASiC-S) is a simple container to associate one or more signatures with a single data object. The 
signatures are carried in a single signature structure which may either be: 

• a single CAdES signature which may contain parallel signatures; each of them can further be individually 
counter-signed; or 

• multiple XAdES signatures using the new structure defined in clause A.4; each of them can further be 
individually counter-signed; or 

• a single TST. 

The container contains only the data object and the signature or the time-stamp token that applies to it, with an optional 
mimetype. Parallel signatures are supported and it is possible to add at a later time additional signatures to the same data 
object. The signed data object can itself be a container nested within the ASiC container. 

The second is an extended container (ASiC-E) that contains multiple data objects. Each data object may be signed by 
one or more signature structures carried in the container. 

Each signature structure may be either: 

• a single CAdES signature which may contain parallel signatures; each of them can further be individually 
counter-signed; or 

• one or more XAdES signatures using the new structure defined in A.4; each of them can further be 
individually counter-signed; or 

• a single TST. 

This second type of container is compatible with OCF, UCF and ODF formats. 

Data objects are signed, together with some metadata and each signature is associated with all or some of the data 
objects in the container. It is possible to add signatures and data objects to an Extended ASiC and the additional 
signatures can apply to the same or different set of data objects, without invalidating previously applied signatures. 
Later signatures may sign signatures applied previously. 

ASiC is based on Advances Signatures based on CAdES [1] or XAdES [2] formats or time-stamp tokens conformant 
to [13]. 

NOTE 1 : Future versions of the present document may support additional formats. 

NOTE 2: The present document does not support storage of additional information that might be required for long 
term verification of time-stamps; this issue can be covered by future versions of the present document. 
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All ASiC container types support parallel signatures. 

4.3 Compliance with external specifications 

The extended ASiC type can be used in a way which is compatible with OCF, UCF and ODF. These containers define a 
structure with metadata about its content. 

The following are examples of data elements from these formats that can be used with ASiC: 

• "mimetype" containing the mime type to identify the selected container type, conforming to relevant clauses in 
the present document (supported by OCF, UCF and ODF). 

• "META-INF/container.xml" allowing to specify one or more root data objects to specify how to start 
processing the container (mandatory in OCF, not allowed by ODF and not required by UCF). 

• "META-INF/manifest.xml" additional metadata about container content - (allowed by OCF and UCF and 
mandatory in ODF). 

• "META-INF/metadata.xml" that can contain user defined metadata associated with data objects (allowed by 
OCF and UCF not allowed by ODF). 

• "META-INF/*signatures*.xml" that provide support to include one or more XML signatures, each one of them 
applicable to some or all the data objects present in the ASiC container. Electronic signature is allowed by 
OCF, ODF and UCF but with slightly different syntaxes, all supported by the present document with specific 
provisions in clause 6. 

These and other elements of the OCF, UCF and ODF formats may be combined within ASiC as appropriate, see 
annex C for an informative cross reference of possible content in different containers. 



Associated Signature Simple form 



This clause defines the form of simple Associated Signature Containers ASiC-S that associates a single data object with 
one or more detached signature(s) or a single time-stamp token that applies to it. This form supports the use of CAdES 
or XAdES signatures as well as time-stamp tokens. The time-stamp token is a binary representation of 
TimeStampToken as defined in RFC 3161 [3]. 

ASiC-S is also applicable when the signed data object is itself a container, for example ZIP, OCF, ODF, UCF, or 
another ASiC. In this case it associates the inner container with one or more signatures or a time-stamp token that 
applies to it. Examples of the use of ASiC-S are given in clause B.l. 

5.1 General Requirements for ASiC-S 

The ZIP format [8] with the structure specified in clause 5.2.2 shall be used to bind the contained objects into a single 
container. 

Implementations may support ASiC-S for a single form type (i.e. with at least one of CAdES or XAdES or 
RFC 3161 [3] time-stamp token). 

NOTE: Future versions of the present document may allow use of other signature formats. 

5.2 Detailed format for ASiC-S 
5.2.1 IVIedia type identification 

1) File extension: ".asics" should be used (".scs" is allowed for operating systems and/or file systems not 
allowing more than 3 characters file extensions). In the case that the container content is to be handled 
manually, the ".zip" extension may be used. 
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2) Mime type: implementers may use "application/vnd.etsi.asic-s+zip" to identify this format or may maintain 
the original mimetype of the signed data object. 

3) The comment field in the ZIP header may be used to identify the type of the data object within the container. 
If this field is present, it should be set with "mimetype=" followed by the mime type of the data object held in 
the signed data object. 

5.2.2 Contents of the container 

This container is built using the following internal structure: 

1) An optional "mimetype", defined in clause A.l, containing the mime type as defined in clause 5.2.1 item 2. If 
the container file extension does not imply use of ASiC then the "mimetype" shall be present and the first 
option in clause 5.2.1 item 2 applies. 

2) The signed data object in the root level of the container. It shall be the only data object present at the container 
root level besides the eventual "mimetype" specified in item 1) above. 

NOTE 1 : The signed object can be itself a container, for example in one of the following formats: ZIP, ASiC, OCF, 
ODF or UCF. 

3) The META-INF folder containing one of: 

a) "timestamp.tst" containing a binary TimeStampToken as defined in RFC 3161 [3], calculated over the 
entire binary content of the data object specified in item 2; or 

b) "signature.p7s" containing the detached signature in CAdES format of the data object specified in item 2. 
Multiple parallel signatures and countersignatures are allowed, provided they are all collected in the 
same CAdES structure; or 

c) "signatures. xml" containing the root element <asic : XAdESSignatures> as specified in clause A. 5, 
containing one or more detached ds:Signature elements signing the whole data object specified in item 2 
and conformant to XAdES. For ASiC-S ds:Reference shall be used to reference the data object in the 
container and the rules specified in A.6 shall apply. In case referencing attributes (Id, URI or Type) are 
not present in ds:Reference element then a reference to the signed content is implied. Only standard 
canonicalization transformation are allowed in ASiC-S. 

NOTE 2: In the case of use of implied reference the party verifying the signature is aware of the application context 
and the expected relation between the signed data object and the signature. Use of implied reference gives 
greater flexibility for the application's use of ASiC in positioning the signature relative to the data. Use of 
relative references requires the relative positioning to be maintained when data is extracted from the 
container if signatures are still to be verifiable. 

Other application specific information may be added in further metadata objects contained within the META- 
INFO directory. 

If a time-stamp token is applied to an ASiC-S containing a signed container, provided all the verification data is 
correctly referenced in the time-stamped data object, it can extend the signature validity. 
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Figures 1 to 5 illustrate examples for the content of the ASiC-S container. 



mimetype 

dataobject.pdf 

META-INF/ 
signature. p7s or 
signatures, xml or 

timestamp.tst 



application/vnd.etsi.asic-s+zip 



An example signed object 



CAdESorXAdES detached Signature(s) [.»• 
or Time-stamp 



Figure 1 : ASiC-S structure applied to a plain data object 
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Figure 2: ASiC-S structure applied to a nested container 



5.3 Mime type correlation check 



If the "mimetype" is present conformant implementations shall check that it is consistent with provisions in clause 5.2. 1 
item 2 and clause 5.2.2 item 1. 



Associated Signature Extended form 



The Extended ASiC container types support one or more signatures and time-stamp tokens each applicable to its own 
set of one or more data objects. Each data object can have associated additional information and metadata that can also 
be protected by any of the signature(s) present in the container. The container packages all the mentioned elements. The 
container can be designed to prevent any further modification or allowing that additional data objects and signatures can 
be included at a later time to the container without breaking the previous signatures. 

Two Extended ASiC structures are defined: 

1) Associated Signature Container Extended form using XAdES: the data objects are associated with signatures 
in XAdES format. 

2) Associated Signature Container Extended form using CAdES or Time-Stamp Tokens: the data objects are 
associated with signatures in CAdES format or with Time Stamp Tokens. 
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All ASiC types allow container nesting (with inner containers being themselves ASiC or any type of container) 
allowing arbitrary complex hierarchies to be represented. 

The clauses in this section specify Extended ASiC structures. Clauses 7.2.1, 7.2.2 and 7.2.3 refer to specific clauses and 
items in this section that implementations claiming conformance to each ASiC form shall conform to. When using 
ASiC with an external specification, applicable clauses and items that implementations shall conform to are specified in 

clause 7.2.4. 

6.1 General Requirement of ASiC-E 

The ZIP format [8] shall be used to bind the contained objects into a single container. 

Implementations may support just the ASiC-E for a single form type (i.e. with at least one of CAdES, time-stamp token 
or XAdES); see clauses 7.2.1, 7.2.2 and 7.2.3 for more details. 

6.2 Detailed format for ASiC-E with XAdES 

The structure specified in clause 6.2.2 shall be used to build the container. 

One or more signatures can be present in this form type. Each signature can contain an arbitrary number of ds:Signature 
elements, each signing an arbitrary set of data objects within the container that shall be referenced according to rules 
defined in clauses A. 6 and 6.2.4. 

6.2.1 Media type identification 

1) File extension: ".asice" should be used (".see" is allowed for operating systems and/or file systems not 
allowing more than 3 characters file extensions). 

2) Mime type: "application/vnd.etsi.asic-e+zip" mime type should be used to identify the format of this 
container. 

3) The comment field in the ZIP header may be used to identify the type of content within the container. If this 
field is present, it should be set with "mimetype=" followed by the mime type defined above. 

6.2.2 Contents of Container 

Signatures associated to data objects are based on XAdES signatures. Clauses A.6 and 6.2.4 specify the rules on 
referencing signed data objects. 

This container is in zip format with the content and internal structure defined as follows: 

1) An optional "mimetype", defined in clause A.l, containing the mime type as defined in clause 6.2.1, item 2. If 
the container file extension does not imply use of a supported container format then the "mimetype" shall be 
present. 

2) One or more "META-INF/*signatures*.xml" shall be present containing one or more XAdES signatures 
conforming to TS 101 903 [2] as specified in the following item. Signed data objects may either be directly 
referenced by each signature with a set of <ds : Reference > elements or may be indirectly referenced using a 
<ds :Manifest> object that is pointed by a <ds :Reference>, following the rules specified in clause 6.2.4. 

3) The root element of each "META-INF/*signatures*.xmr' content shall be either: 

a) <asic : XAdESSignatures> as specified in clause A. 5, the recommended format; or 

b) <document-signatures> as specified in OASIS Open Document Format [9]; or 
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c) <signatures> as specified in OEBPS Container Format (OCF) [7]. 

All the root elements inside the signature files in a given container shall be the same. 

NOTE 1: As specified in clause A.4 and in OCF [7] and ODF [9], in either case the child elements of the root 

element are one or more <ds:Signature> sibling elements as specified in W3C recommendation: "XML 
Signature Syntax and Processing" [10]. 

4) Other application specific information may be added in further files contained within the META-INF 
directory, such as: 

a) "META-INF/container.xml" if present shall be well formed XML conformant to OEBPS Container 
Format (OCF) [7] specifications. It shall identify the MIME type and full path of all the root data objects 
in the container, as specified in OCF. 

b) "META-INF/manifest.xml" if present shall be well formed XML conformant to OASIS Open Document 
Format [9] specifications. 

NOTE 2: according to ODF [9] specifications, inclusion of reference to other META-INF information, such as 
META-INF/*signatures*.xml, in manifest. xml is optional. In this way it is possible to protect the 
container's content signing manifest.xml while allowing to add later signatures. 

c) "META-INF/metadata.xml" has a user defined content. If present, its content shall be well formed XML 
conformant to OEBPS Container Format (OCF) [7] specifications. 

6.2.3 ASiC-E with XAdES example (informative) 

In figure 3 is represented a typical structure for this container where the XMLDSig [10] element ds:Reference is used 
directly to reference the signed objects. Implementers are advised that use of ds:Manifest requires special attention and 
specific requirements are given in clause 6.2.4. 













mimetype 


application/vnd.etsi.asic-e-Hzip 












filel.xml 


<docunient> . . . </docurTient> 


«*% 






■ 
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file2.gif 


^ 


«...: 


IV1ETA-INF/ 
containerxml 
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<ocf ;cortairer> </ocf ;cortairer> 


'■/•/ 




* J ' 
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META-INF/ 
signature.xml 


<asic;XAdESSigratures> / 
<ds;Sigratijre ..> ^»* y 
<cls:Signecllrfo> /* / 
<cls;Reference URI=filel.xml>...<Digest., .>..** y* .*' 
<ds:Reference URI=file2.gif>...<Digest...>.,. ** y* 
<ds:Reference URI=container.xml>...<Digest.,.>.* 


•>... 









Figure 3: ASiC-E with XAdES and direct ds:reference usage 

6.2.4 XAdES use in ASiC-E witin XAdES 

For ASiC-E used with XAdES the rules specified in clause A. 6 shall apply. 

To reference the signed data objects ds:Reference should be used in preference to ds:Manifest. 
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In the case that ds:Manifest element is used the following restrictions shall apply: 

1) The ds:Manifest containing ds:Reference elements referencing the signed data objects shall be signed 
(i.e. shall be referenced within ds:SignedInfo element and its contents contribute to the ds:Signature Value 
content). 

2) The ds:Manifest elements shall not reference other ds:Manifest elements within a ds: Signature (i.e. direct 
chaining of ds:Manifest is not allowed). 

3) Applications claiming compliance with the present document, shall raise a warning whenever a digest value 
mismatch is detected within any ds:Manifest's ds:Reference child (i.e. the digest computed over the referenced 
data object and the ds:DigestValue within this ds:Reference do not match), even if the cryptographic 
verification of the ds:SignedInfo succeeds (i.e. if the signature value computed by the verifying application 
actually matches ds:Signature Value's content). 

4) For referencing the ds:Manifest element from the ds:Reference element in the corresponding signature an Id 
attribute should be used. 

The process for the verification of the ds:Manifest is outside the scope of the present document. 

6.3 Detailed format for ASiC-E with CAclES and Time Stamp 
Tokens 

The ASiC-E form can be used to apply CAdES signatures and time-stamp tokens to a set of data objects. 
Each CAdES signature allows presence of parallel signatures and countersignatures. 

6.3.1 IVIedia type identification 

1) File extension: ".asice" should be used (".see" is allowed for operating systems and/or file systems not 
allowing more than 3 characters file extensions). 

2) Mime type "application/vnd.etsi.asic-e+zip" mime type should be used to identify the format of this container. 

3) The comment field in the ZIP header may be used to identify the type of content within the container. If this 
field is present, it should be set with "mimetype=" followed by the mime type defined above. 

6.3.2 Contents of Container 

This container is in zip format with the content and internal structure defined as follows: 

1) An optional "mimetype" containing the mime type defined in clause 6.3.1, see clause A.l for requirements on 
encoding mimetype. 

2) Any number of data objects that can be digitally signed arbitrarily structured in folders. 

3) At least one "META-INF/ASiCManifest*.xmr', with the content specified in clause A.4, shall be present. 

4) For each "META-INF/ASiCManifest*.xmr' a time-stamp token or a signature that applies to it shall be 
present named as follows: 

a) "META-INF/*signature*.p7s" containing a CAdES signature conforming to TS 101 733 [1]; or 

b) "META/INF/*timestamp*.tst" containing a binary TimeStampToken as defined in RFC 3161 [3]. 

Implementations claiming conformance to ASiC-E with CAdES, according to clause 7.2.2, and/or time-stamp token, 
according to clause 7.2.3, shall: 

1) verify the signature or time-stamp, as applicable; 

2) verify that the content signed or time-stamped conforms to clause A.4; 
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3) raise an error whenever a digest value mismatch is detected within any ds:DigestValue in 

asic:DataObjectReference and the digest computed over the referenced data object, even if the cryptographic 
verification of the signature or time-stamp token succeeds. 

NOTE 1 : Users verifying this container type using a CAdES implementation not aware of ASiC specific rules are 
warned that any data objects referenced by the signed data may not be checked. 

NOTE 2: In order to enable use of existing CMS/CAdES implementations as the basis for ASiC, no specific 
contentlnfo Object Identifier has been defined to identify the specific type of object being signed. 

Figure 4 shows an example for the content of the ASiC-E where a CAdES signature is applied to a set of data objects. 



mimetype 

filel.pdf 
file2.gif 

METAINF/ 
ASiCManifest.xml 



opplication/vnd.etsi.asic-e+zip 



An example document 



fl"0 



«..^ 



■- ASi CM ani f est> 

■rSig-Reference URI="META-INF/sig:nature.p7s... 
or 

<SiffReference URI-'META-INF/timestamp.tst.. 

**' ■ 

<DataObjectReferance>URI=filel.pdf..-<Oigest..>*.. ,* 

<DataObjecfReference>URI=file2.gif...<DigGst.. >".■•** 






META-INF/ 
signature. p7s or 
timestamp.tst 



CAcIES detached Signatur-e{s) or RFC 3161 
Time-stamf5 token applied to ASiCManifest.xml 



Figure 4: ASiC-E with CAdES signature 

This container format allows the application of different CAdES signatures and/or time-stamp tokens to different set of 
data objects, as shown in figure 5. 
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Figure 5: ASiC-E with CAdES containing different signatures 



6.4 Mime type correlation check 



If the "mimetype" is present conformant implementations shall check that it is consistent with clause 6.2.1 item 2 and 
clause 6.2.2 item 1. Also, if the META-INF includes manifest objects containing the mimetype of the object referenced 
(e.g. ASiCManifest*.xml) implementations shall check that this is coherent with the object referenced. 



Conformance requirements 



The present clause specifies conformance requirements for the generation and/or verification of the Associated 
Signature Containers specified in the present document. 

An implementation can claim conformance to ASiC if it supports at least one of the following Conformance Clauses. 
Conformance to any set of the following Conformance Clauses may be claimed and explicit reference to those 
supported may be used to profile specific interoperable implementations. 



7.1 



ASiC-S conformance 



Implementations claiming conformance to ASiC-S shall meet the requirements of the present document for generating 
and/or verifying Simple Associated Signature Type (ASiC-S) as specified in one or more of the following clauses. 

7.1 .1 ASiC-S CAdES Conformance Clause 

Implementations claiming conformance to this clause shall meet the requirements specified in clauses 5.1, 5.2.1 and 
shall5.2.2 items 1, 2 and 3b. A verifying implementation shall support clause 5.3. 

7.1 .2 ASiC-S XAdES Conformance Clause 

Applications claiming conformance to this clause shall meet the requirements specified in clauses 5.1, 5.2.1 and 5.2.2 
items 1, 2 and 3c. A verifying implementation shall support clause 5.3. 
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7.1 .3 ASiC-S Time-stamp token Conformance Clause 

Implementations claiming conformance to this clause shall meet the requirements specified in clauses 5.1, 5.2.1 and 
5.2.2 items 1, 2 and 3a. A verifying implementation shall support clause 5.3. 

7.2 ASiC-E conformance 

Implementations claiming conformance to ASiC-E shall meet the requirements specified in the present document for 
generating and/or verifying Extended Associated Signature Type (ASiC-E) as follows. 

7.2.1 ASiC-E XAdES Conformance Clause 

Implementations claiming conformance to this clause shall meet the requirements specified in clauses 6.1, 6.2.1 and 
6.2.2. Furthermore, the implementation shall support: 

• At least one of the media type identification specified in clause 6.2.1 and both items 1 and 2 should be 
supported. 

• At least one of the content specified in clause 6.2.2 item 4a or 4b. 
A verifying implementation, shall support clause 6.4. 

7.2.2 ASiC-E CAdES Conformance Clause 

Implementations claiming conformance to this clause shall meet the requirements specified in clauses 6.1, 6.3.1 and 
6.3.2 (excluded item 4b unless conformance to ASiC-E Time-stamp is also claimed). If a verifying implementation, it 
shall support clause 6.4. Furthermore, the implementation shall support at least one of the media type identification 
specified in clause 6.3.1 items 1 and 2 and should support both. 

7.2.3 ASiC-E Time-stamp token Conformance Clause 

Implementations claiming conformance to this clause shall meet the requirements specified in clauses 6.1, 6.3.1 and 
6.3.2 (excluded item 4a unless conformance to ASiC-E CAdES is also claimed). If a verifying implementation, it shall 
support clause 6.4. Furthermore, the implementation shall support at least one of the media type identification specified 
in clause 6.3.1 items 1 and 2 and should support both. 

7.2.4 ASiC-E other container Conformance Clause 

Implementations claiming conformance to this clause are expected to claim conformance also to an external container 
technical specification or standard. In addition, such implementations shall support the clauses 6. 1 and 6.2.2 items 2 
and 3, that shall have precedence over the external specification requirements. 

Additional requirements specified in clause 6 apply if not in contradiction with the external specification. 
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Annex A (normative): 

ASiC metadata specification and data naming and 

referencing 

This annex contains the definition of ASiC specific content or additional specification for metadata already defined in 
other container formats and specify data objects and metadata naming and referencing rules. 



A.1 IVIimetype 



The "mimetype" object, when stored in a ZIP, file can be used to support operating systems that rely on some content in 
specific positions in a file (the so called "magic number" as described in RFC 4288 [11] in order to select the specific 
application that can load and elaborate the file content. The following restrictions apply to the mimetype to support this 
feature: 

• it has to be the first in the archive; 

• it cannot contain "Extra fields" (i.e. extra field length at offset 28 shall be zero); 

• it cannot be compressed (i.e. compression method at offset 8 shall be zero); 

• the first 4 octets shall have the hex values: "50 4B 03 04". 

An application can ascertain if this feature is used by checking if the string "mimetype" is found starting at offset 30. In 
this case it can be assumed that a string representing the container mime type is present starting at offset 38; the length 
of this string is contained in the 4 octets starting at offset 18. 

All multi-octets values are little-endian. 

The "mimetype" shall NOT be compressed or encrypted inside the ZIP file. 

A.2 IVIIIVIE registrations 

The following MIME-Types and file-extensions are used in the present document: 

NOTE: At the time of publication the MIME-Types are undergoing registration procedure with lANA and users 
are advised to make their own checks for completion of these formalities (the list of Directories of 
Content Types and Subtypes can be found here: http://www.iana.org/assignments/media- 
types/application/) . 

MIME media type name: Application. 

MIME subtype name: vnd.etsi.asic-sH-zip. 

Required parameters: none. 

encoding considerations: will be none for 8-bit transports and base64 for SMTP or other 7-bit transports. 

File extension: asics or scs. 

MIME media type name: Application. 

MIME subtype name: vnd.etsi.asic-e-nzip. 

Required parameters: none. 

encoding considerations: will be none for 8-bit transports and base64 for SMTP or other 7-bit transports. 

File extension: asice or see. 

MIME media type name: Application. 

MIME subtype name: vnd.etsi.timestamp-token. 

Required parameters: none. 

encoding considerations: will be none for 8-bit transports and base64 for SMTP or other 7-bit transports. 

File extension: tst. 
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Security considerations: The data objects carried in ASiC container may contain malicious code and hence 

unless the source is trusted the usual protection against malware and viruses should be 
applied. 

Published specification: The ASiC formats as defined in the present document. 



A.3 ASiC XML Schema 

The following namespace declarations apply for the XML Schema definitions throughout the present document 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xsd: schema 

targetNamespace="http: //uri .etsi .org/ 02 918 /vl . 1 . 1#" 
xmlns :ds="http: //www.w3 .org/2 000/0 9/xmldsig#" 
xmlns="http : //uri . etsi .org/02 918 /vl . 1 . 1#" 
xmlns :xsd="http: //www.w3 . org/2 1/XMLSchema" 
elementFormDefault=" qualified" 
attributeFormDefault=" unqualified" > 
<xsd: import 

namespace="http : //www. w3 . org/2 0/09/xmldsig#" 

schemaLocation="http : //www. w3 . org/TR/2 02/REC-xmldsig-core-2 02 0212/xmldsig-core- schema .xsd"/> 

This XML Schema shown in the present annex is held in the file ts_102918v010201p0.zip attached to the present 
document as a normative part. 

The hash values for this file are: 

MD-5: 43:la:a9:d8:ca:12:dl:f4:ab:34:8e:98:58:21:8a:fl 

SHA-1: 39:c6:2f:e8:26:a8:lf:d9:57:ab:e5:10:10:9d:55:41:d6:5d:64:5c 

SHA-256: aa:64:2c:60:8d:40:44:15:81:23:0a:0a:d9:b0:a5:72:d8:93:b3:82:d3:2b:10:c4:77:81:f5:b4:83:37:cl:bf 
The following clauses describe the content of this XML Schema. 



A.4 ASiCManifest content 



ASiCManifest content is conformant to the ASiC XML Schema. Here follows an extract of this schema, relevant to 
ASiCManifest: 

<xsd:element name="ASiCManif est" type="ASiCManif estType" > 
<xsd : annotation> 

<xsd:documentation>Schema for ASiC-E with CAdES and/or Time-Stamp tokens, specifying 
content for ASiCManifest .xml</xsd:documentation> 
</xsd : annotation> 
</xsd : element> 

<xsd: complexType name="ASiCManif estType" > 
<xsd: sequence> 

<xsd : element ref = " SigRef erence " / > 

<xsd: element ref ="DataObjectRef erence" maxOccurs= "unbounded" /> 

<xsd:element name="ASiCManif estExtensions" type="ExtensionsListType" minOccurs="0"/> 
</xsd : sequence> 
</xsd : complexType> 

<xsd: element name=" SigRef erence" type="SigRef erenceType"/> 
<xsd: complexType name="SigRef erenceType" > 

<xsd: attribute name="URI" type="xsd: anyURI" use=" required" /> 
<xsd: attribute name="MimeType" type="xsd: string" use="optional"/> 
</xsd : complexType> 

<xsd : element name= " DataOb j ectRef erence " type = " DataOb j ectRef erenceType " / > 
<xsd: complexType name="DataObj ectRef erenceType" > 
<xsd : sequence> 

<xsd: element ref ="ds :DigestMethod"/> 
<xsd: element ref ="ds : Digest Value "/> 

<xsd: element name="DataObjectRef erenceExtensions" type=" Ext ens ionsList Type" minOccurs="0"/> 
</xsd : sequence> 
<xsd: attribute name="URI" type="xsd: anyURI" use=" required" /> 
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<xsd: attribute name="MimeType" type="xsd: string" use="optional" /> 
<xsd: attribute name="Rootf ile" type="xsd: boolean" use="optional" /> 
</xsd : complexType> 
<xsd: complexType name="AnyType" mixed="true" > 

<xsd: sequence minOccurs="0" maxOccurs="unbounded" > 

<xsd:any processContents="lax"/> 
</xsd : sequence> 
</xsd : complexType> 

<xsd:element name=" Extension" type="ExtensionType"/> 
<xsd: complexType name="ExtensionType" > 
<xsd: complexContent> 

<xsd: extension base="AnyType"> 

<xsd: attribute name="Critical" type="xsd:boolean" use="required"/> 
</xsd:extension> 
</xsd: complexContent> 
</xsd : complexType> 

<xsd: complexType name="ExtensionsListType" > 
<xsd : sequence> 

<xsd:element ref ="Extension" maxOccurs="unbounded"/> 
</xsd : sequence> 
</xsd : complexType> 

Here follows the description of all the xml tags defined in this schema: 

• ASiCManif est : root element. It defines, with all the elements it includes, the content of ASiCManifest.xml 
metadata used in ASiC-E with CAdES and/or Time-Stamp tokens. It contains one element SigRef erence 
and one or more DataOb j ectRef erence. Additional Extension elements can be added inside in the 
optional ASiCManif estExtensions element to extend the semantic at the root schema level. 

• SigRef erence : this element contains an URI element pointing to the CAdES signature or the time-stamp 
token that applies to the ASiCManifest.xml metadata and the related MimeType . 

• DataObj ectRef erence : this element contains an URl, a MimeType and an optional Rootfile, referencing 
respectively a data object, its MIME type a Boolean Rootfile attribute that, if present and set to "true" specify 
it is a root file with same meaning specified by OCF clause 3.5.1; this element contains ds :DigestMethod 
and ds :DigestValue set with the digest algorithm and the related HASH value calculated on the data object. 
There is a DataObj ectRef erence element for each data object referenced by ASiCManifest. Other 
Extension elements can be added in the optional DataObj ectRef erenceExtensions element to extend 
the semantic associated to each data object referenced by this schema. 

• Extension : this element can contain an arbitrary content, provided it is well formed XML, that can be used 
to extend the semantic of this schema. 

The ds : DigestMethod and ds : Digestvalue elements are defined in XMLDig. 



A.5 XAdESSignatures content 



XAdES Signatures is an XML schema to include any number of ds: Signature elements in a single valid XML data and 
can be also used outside the context of the present document for the same purpose. 

XAdESSignatures content is conformant to the ASiC XML schema attached to the present document as specified in 
clause A. 3 and here follows an extract, relevant to XAdES Signature: 

<xsd:element name= "XAdESSignatures" type="XAdESSignaturesType" > 

<xsd : annotation> 

<xsd:documentation>Schema for parallel detached XAdES Signatures </xsd:documentation> 

</xsd:annotation> 
</xsd: element > 
<xsd: complexType name="XAdESSignaturesType" > 

<xsd : sequence> 

<xsd:element ref ="ds : Signature" maxOccurs="unbounded"/> 

</xsd : sequence> 
</xsd : complexType> 
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The root element XAdESSignatures contains one or more ds : Signature elements containing each a detached 
signature conformant to XAdES. 



A. 6 Naming and referencing data within ASiC 

ZIP format specification [8] defines a cross-platform file storage and transfer format. In the present document the terms 
"data object" or "metadata" indicate information stored in the container using the ZIP format without assuming any 
particular data storage technology. 

Data objects and metadata can be hierarchically structured in folders as allowed by files in the ZIP format. 

Valid data object and metadata naming shall comply with the ZIP specification [8] and any applicable specific 
container specification the implementation claims to be compliant with. In this document the character "*" used to 
indicate an arbitrary character string of any length, including zero, chosen by the specific implementation to compose a 
valid file name. 

EXAMPLE: "xxxx/yyyy*.ext" indicates a data object in the "xxxx" folder whose name begins with "yyyy" 

followed by any allowed character and terminating with ".ext". Possible values that comply with 
this example are "xxxx/yyyy.ext" or "xxxx/yyyy-I234.ext". 

In ASiC containers signed data objects are referenced using ASiCManifest (defined in clause A.4) for ASiC-E with 
CAdES and according to clauses 5.2.2 item 3c for ASiC-S using XAdES and clause 6.2.4 for ASiC-E with XAdES. 

The following rules shall apply to these references, expressed as URIs (as defined in [12]): 

1) Reference to data objects within the container shall be relative URIs. A specific behaviour is defined for 
relative URIs in the context of an ASiC container metadata, stored in the "META-INF" folder, as allowed by 

clause 5.1.4 of [12]: 

a) When the relative URI contains an absolute path, it is resolved relative to the container root directory. 

b) When the relative URI contains a relative path, it is resolved using the root directory as the base URI, not 
taking into account the "META-INF" folder where signature metadata are stored. 

2) Reference to data objects outside the container shall not be allowed. 

ASiC signatures are located in META-INF directory. According to these rules, references to data objects internal to the 
container are relative to the root folder: for example, to reference a data object named "document.xml" in the root 
directory, correct references are "document.xml" or "/document.xml". 

When an ASiC-E container implementation claims compliance to an external technical specification or standard 
(according to clause 7.2.3) that define different referencing rules, they shall prevail. 

NOTE: For referencing data objects for different purposes that electronically signing them, implementers are 

encouraged to use the same rules defined in this clause (considering that rule in item 2b can be extended 
to any metadata contained in the META-INF directory) when applications do not have specific 
requirements to implement different rules. These rules, in fact, are mostly compatible with the rules 
defined in OCF, UCF and ODE. 
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Annex B (informative): 

Example Application to Specific File Formats 

Examples of the application of the present document to use case are described in this annex. 
This includes: 

• ASiC-S: use cases to associate to a single data object, that itself can be a container, one or more detached 
signatures or a time-stamp token that applies to it and to combine them in a container. 

• ASiC-E with XAdES: use cases to have one or more XAdES signatures each applicable to a set of data 
objects. Additional metadata, applicable to data object, can also be protected by signature. 

• ASiC-E with CAdES: use cases, same as the use cases above, but applying CAdES signatures or time 
stamping to a set of data objects. 



B.1 Examples of ASiC-S 



A very common requirement is to hold together a single document with its detached digital signature or its document 
time-stamp. This example is for a PDF document with a CAdES signature. The equivalent structure may be applied to 
any form of single document or data format including XML, spreadsheet, TIFF, graphic, video. Similarly, the ASiC-S 
structure can use other form of signature or time-stamp token including XAdES and RFC 3161 [3] time-stamp token. 

ASiC-S offers a standardized solution suitable for any use case where one or more signatures, or time-stamp tokens are 
appUed to a single data object. 

B.1 .1 PDF document Associated with CAdES Signature 

This use case proposes a way to associate a PDF document with an advanced signature that applies to it. 
The following data objects are put in the container: 

• "mimetype", containing "application/vnd.etsi.asic-sH-zip". 

• "filel.pdf , containing the PDF document to be signed. 

• "/META-INF/signatures.p7s" containing the CAdES signature created from the hash value offilel.pdf. 



B.1. 2 Simple document time stamp 



If there is the need to associate a time-stamp token with a data object to which the time-stamp token applies, the 
following data objects are put in the container: 

• "mimetype", containing "application/vnd.etsi.asic-sH-zip". 

• "filel.pdf, containing the PDF document time-stamped. 

• "/META-INF/timestamp.tst" containing the RFC 3161 [3] time-stamp created from the hash value offilel.pdf. 



B.1. 3 Signature of a ZIP file 



A possible variant of the example given above is where several documents, in the same or different formats, are all to be 
signed with the same signature or time-stamp token. In this example, a CAdES signature is used. The same basic 
structure can be used with a XAdES signature or time-stamp token. 
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A set of documents to be signed are placed together in a ZIP file named "inner-container.zip". For example: 

• "filel.pdf , containing a PDF document. 

• "file2.xml", containing XML data. 

• "pictures .png" containing a graphical object. 

This is placed in an outer container "outer-container.zip" as follows: 

• "mimetype", containing "application/vnd.etsi.asic-s+zip". 

• "inner-container.zip", with the container to be signed. 

• "/META-INF/signatures.p7s" containing the CAdES signature created from the hash value of 
inner-container.pdf. 

B.2 Example of ASiC-E with XAdES 

In this example more than one document or data object has to be signed with a XAdES signature. 
In this example, two XML documents are signed and placed in a container. 
The container is produced in a ZIP that includes: 

• "mimetype", containing "application/vnd.etsi.asic-e+zip". 

• "filel.xml", containing the first XML document. 

• "file2.xml", containing second XML document. 

• "/META-INF/signatures.xml" containing two signatures, the first signing filel.xml and file2.xml and the 
second signing only filel.xml, as described below. 

META-INF/signatures.xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<asic: XAdESSignatures 

xmlns :ds="http: //www.w3 . org/2000/09/xmldsig#" 

xmlns :asic="http: //uri . et si . org/02 918 /vl . 1. 1#" 

xmlns :xsi="http : //www.wS . org/2 1/XMLSchema- instance" 

xmlns :xades="http: //uri . et si . org/01903 /vl . 3 .2#"> 
<ds : Signature> 

< ! - - ... - - > 

<ds :Ref erence URI="f ilel .xml" > 

<! -- ... --> 
</ds : Re f erence > 

< ! - - ... - - > 

<ds iReference URI="f ile2 .xml" > 

<! -- ... --> 
</ds : Re f erence > 

< ! - - ... - - > 
</ds : Signature> 
<ds : Signature> 

< ! - - ... - - > 

<ds iReference URI="f ilel .xml" > 

<! -- ... --> 
</ds : Ref erence> 

< ! - - ... - - > 

< ! - - ... - - > 
</ds : Signature> 

</asic :XAdESSignatures> 
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B.3 Example of ASiC-E with CAdES 

In this example more than one document or other type of data object is to be signed with a CAdES signature and 
time-stamped. In this case, a different set of documents are to be protected by the time-stamp token from those that are 
signed. Many examples exist with a number of signatures/time-stamp tokens protected different data objects, for 
example when documents progress through a workflow. 

In this example, two XML documents are signed and placed in a container. Subsequently, PDF transforms of the two 
XML documents are produced and to bind them to the XML documents both the XML documents and the PDF 
documents are time-stamped. 

The first version of the container is produced in a ZIP file containing: 

• "mimetype", containing "application/vnd.etsi.asic-e-nzip". 

• "fileLxml", containing the first XML document. 

• "file2.xml", containing second XML document. 

• "/META-INF/ASiCmanifestl.xml" containing the hash of fileLxml and file2.xml. 

• "/META-INF/signatures 1 .p7s" containing the CAdES signature of "/META-INF/asicmanifestl .xml. 
Subsequently the container is updated and the ZIP file is updated to contain (added content in bold): 

• "fileLxml", containing the first XML document. 

• "file2.xml", containing second XML document. 

• "filel.pdf", containing the first document in PDF. 

• "file2.pdf", containing the second document in PDF. 

• "/META-INF/ASiCmanifestl.xml" containing the hash of fileLxml and file2.xml. 

• "/META-INF/signature.p7s" containing the CAdES signature of "/META-INF/asicmanifestl.xml. 

• "/META-INF/ASiCmanifest2.xml" containing the hash of filel.xml, file2.xml as well as filel.pdf, 
file2.pdf. 

• "/META-INF/timestamp.tst" containing the time-stamp token applied to "/META- 
INF/ASiCmanifest2.xml. 

META-INF/ASiCmanifestI .xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<asic lASiCManif est 

xmlns :ds="http: //www.w3 . org/2 000/09/xmldsig#" 
xmlns :asic="http: //uri .etsi .org/02 918 /vl . 1 . 1#" 
xmlns :xsi="http : //www.w3 . org/2 1/XMLSchema- instance" > 
<asic : SigRef erence URI="META- INF/signature .p7s" 

MimeType="application/x-pkcs7- signature" /> 
<asic iDataObjectRef erence URI="DOCUMENTS/f ilel .xml" MimeType="application/xml" > 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds :DigestValue>j61wx3SAvKTMUP4NbeZl</ds : DigestValue> 
</asic : DataObj ectRef erence> 

<asic : DataObj ectRef erence URI="DOCUMENTS/f ile2 .xml" MimeType="application/xml" > 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds :DigestValue>h3isbr37GE6Ek2wa</ds :DigestValue> 
</asic : DataObj ectRef erence> 
</asic lASiCManif est> 
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META-INF/asicmanifest2.xml: 

<?xml version="l . 0" encoding="UTF-8" ?> 
<asic : ASiCManif est 

xmlns :ds="http: //www.w3 . org/2 0/09/xmldsig#" 
xmlns :asic="http: //uri .etsi .org/ 02 918 /vl . 1 . 1#" 
xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 
<asic : SigRef erence URI="META-INF/timestamp . tst" 

MimeType="application/vnd. etsi . timestamp- token" /> 
<asic iDataObjectRef erence URI="DOCUMENTS/f ilel .xml" MimeType="application/xml"> 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds :DigestValue>j61wx3SAvKTMUP4NbeZl</ds : DigestValue> 
</asic : DataObj ectRef erence> 

<asic : DataObj ectRef erence URI =" DOCUMENTS/ file2 .xml" MimeType="application/xml" > 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds :DigestValue>h3isbr37GE6Ek2wauT7J</ds :DigestValue> 
</asic : DataObj ectRef erence> 

<asic : DataObj ectRef erence URI= " DOCUMENTS/ f ilel .pdf " MimeType="application/pdf " > 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds :DigestValue>7GE6Ek3SAvKT3isrvEPO</ds : DigestValue> 
</asic : DataObj ectRef erence> 

<asic : DataObj ectRef erence URI= " DOCUMENTS/ file2 .pdf" MimeType="application/pdf " > 
<ds iDigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#sha256"/> 
<ds:DigestValue>br37GTMU3SAvKT3sbr3I</ds:DigestValue> 
</asic : DataObj ectRef erence> 
</asic : ASiCManif est> 
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Annex C (informative): 

Container metadata information cross reference 

Specification of container formats define a data object structure with metadata about its content, as referenced in 
clause 4.2.1. 

The elements of the OCF, UCF and ODE formats may be combined for use within ASiC as appropriate. 

Table C.l summarizes and compares the different metadata that can be present in each container. 

Table C.1 : Container content comparison 



Container type 
lUletadata in the 
container 


ASiC-E with XAdES 


OCF 


ODF 


UCF 


Mimetype 


Optional - The 
present document 
defines specific 
media types 


Optional. If present 
the content is: 
application/epub+zip 
as defined in 
OCF [7]. 


Optional. If present is 
set to the media type 
associated to the 
OpenDocument 
content carried by the 
container 


Optional 


META-INF/manifest.xml 


Optional 


Optional 


Mandatory 


Optional 


META-INF/metadata.xml 


Optional 


Optional 


Not present 


Optional 


META-INF/container.xml 


Optional 


Mandatory 


Not present 


Optional 


M ETA- INF/ 
*signatures*.xml 


At least one 
signature is present 


Optional; a single file 
is allowed with name 
"signatures. xml"" 


AnyfileinMETA-INF 

containing 

"signatures" 


Optional; a single file 
is allowed with name 
"signatures.xml" 
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